home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 597 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.5 KB
  1. Path: engnews1.Eng.Sun.COM!usenet
  2. From: clamage@Eng.Sun.COM (Steve Clamage)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Paradox due to A7.1 Pointer generation rul
  5. Date: 19 Mar 1996 00:12:46 GMT
  6. Organization: Sun Microsystems Inc.
  7. Message-ID: <4iku5u$btv@engnews1.Eng.Sun.COM>
  8. References: <4ikp70$mkf@franklin.its.utas.edu.au>
  9. Reply-To: clamage@Eng.Sun.COM
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11.  
  12. In article mkf@franklin.its.utas.edu.au, vmm@tasman.its.utas.edu.au (Vishv Malhotra) writes:
  13. >
  14. >In the following function a++; is acceptable but b++; is not.
  15. >
  16. >    void foo(int a[20]) {
  17. >        int b[20];
  18. >
  19. >        a++;
  20. >        b++;
  21. >    }
  22. >
  23. >I understand the reason, but I wish to know if there is any thought
  24. >on elimination the anomaly?
  25.  
  26. You can modify 'a' because its declaration is implicitly rewritten by the
  27. compiler to "int *a".  That is, even though its declaration looks like an
  28. array, "a" is really a pointer variable.
  29.  
  30. You cannot modify 'b' because it is the name of an array, and represents
  31. its address. For example, the following is disallowed for the same reason:
  32.     int x;
  33.     (&x)++; /* error */
  34.  
  35. How would you go about either forbidding a++ or allowing b++, without
  36. also making fundamental changes throughout the language?
  37.  
  38. Personally, I think the array/pointer schizophrenia in C was a mistake, as
  39. it leads to endless confusion and prevents using arrays as first-class
  40. objects. But changing the current relationship of pointers and arrays in C
  41. would break all existing C programs, since even the declaration of main
  42. relies on it.
  43.  
  44. ---
  45. Steve Clamage, stephen.clamage@eng.sun.com
  46.  
  47.  
  48.